前言
前陣子看 ruby newsletter 發現 BaseCamp 團隊出了一本書叫做 Shape Up，看起來跟軟體開發團隊的功能規劃跟執行有關，正好那陣子有相關的討論反覆在 retro meeting 被提起，當時想著也許這本書能提供我們一些不同的觀點，因此找了同事一起第一次辦了讀書會一起看這本書，結束之後覺得收穫豐富，也推薦大家可以閱讀一下！
Shape Up 重點整理
1. 塑造（Shaping）
在 Shape Up 中，Shaping 階段非常重要，它發生在實際開發工作開始之前。 這個階段的目標是將模糊的想法轉化為具體的、可執行的專案提案。
- 界定問題： 塑造的第一步是明確界定要解決的問題，並思考解決方案的價值。 這包括判斷這個功能是否值得投入時間開發，大小必須符合他們制定的週期（六週），以及是否有更簡單的替代方案。
- 找出 key element： 下一步是找出解決方案的 key element。 這個過程需要使用一些工具，例如「Breadboarding」和「Fat marker sketches」。 「Breadboarding」是指用文字描述使用者介面和互動流程，而「Fat marker sketches」則是用粗略的圖像來呈現設計概念。 這些工具可以幫助團隊在不陷入細節的情況下，快速探索不同的設計可能性。
- 預先思考風險： 塑造的最後一步是預先思考可能的風險和漏洞。 團隊需要仔細審視設計方案，找出可能導致開發延遲或失敗的因素，並在開發前盡可能解決這些問題。 書中建議可以邀請技術專家參與這個過程，以確保技術方案的可行性。
breadboarding 指的是模仿電路板的道理，在沒有明確設計的情況下來草擬 / 討論 key component，範例為自動結帳功能：
Fat marker sketches 則適用在腦中的點子不是文字而是圖像的時候，建議用馬克筆直接畫草稿，範例為日曆功能：
2. 賭注（Betting）
塑造階段完成後，他們捨棄傳統的 backlog 模式，團隊會將提案提交到「賭注會議」上，由決策者決定哪些提案值得投入時間開發。 這個過程類似於我們之前討論中提到的「賭注會議」。
- 提案篩選： 在賭注會議上，決策者會根據提案的重要性、可行性、時間成本等因素，決定哪些提案值得開發。 書中提到，Basecamp 的決策者會考慮以下問題：這個問題真的重要嗎？預計的開發時間是否合理？解決方案是否具有吸引力？現在是否是開發這個功能的最佳時機？是否有合適的團隊成員可以執行？
- 控制風險： 他們團隊認為，開發新產品和既有產品的功能應該採取不同的賭注策略。 對於新產品，Basecamp 會先進行研發階段，以驗證產品概念的可行性，然後再進入正式開發階段。 這種做法可以幫助團隊降低開發新產品的風險。
- Cool down： 在每個週期結束之後，他們不會馬上進下一個週期，而是兩週的 cool-down 時間，主要用來規劃下次要做什麼 / 開賭注會議，這期間開發者跟設計師可以做一些想做的事情，比方說修 bug / 找新點子 / 試試新技術
3. 建構（Building）
一旦提案在賭注會議上獲得批准，就會進入建構階段，由開發團隊負責將提案轉化為實際產品。
- 專注於核心功能： 從最有意義的開始做，把最重要的核心想辦法做到可以 demo 的程度，過程中盡量每個人可以獨立作業不被卡住（ex. 前端依靠 shaping 來實作出概念而不是依賴設計稿，後端不用先設計資料庫欄位）
- 進度視覺化： 為了讓專案進度視覺化，BaseCamp 團隊自創了山丘圖（Hill chart）的概念，上坡代表還在探索需要解決的問題，下坡代表探索完畢處於執行階段
- 以用戶需求為核心： 專案完成應以解決用戶實際問題為標準，而不僅僅追求理想的功能。同時，減少不必要的實作範圍並不會降低質量，反而能讓團隊聚焦於核心功能，提升產品的競爭力。
作者認為應該前後端團隊首先專注完成一個可呈現的功能：
山丘圖的上坡部分還在探索有哪些待辦事項，下坡就是執行階段，他們會把不同 scope 放在這個山丘圖中，讓 PM 去檢視每個不同 scope 目前的進度
個人想法
- 透過跟團隊一起閱讀過這本書並討論，更可以理解 PM / 設計師的工作流程跟專注點有哪些地方跟工程師不同，覺得光是這件事情就很有收穫。
- 他們認為的理想流程無法百分之百適用於每個團隊，我們認為影響的因素包括但不限於團隊大小 / 團隊體質 / 產品特性。
- 先為這個功能設定 appetite 我覺得很適用在我自己實驗 side project 身上，過往很容易想做的東西太多最後懶惰而失敗，如果先鎖定一個期限，為這個期限設定一個合理的範圍，也許會是一個比較容易成功的路徑。
